home *** CD-ROM | disk | FTP | other *** search
/ The Hacker Chronicles - A…the Computer Underground / The Hacker Chronicles - A Tour of the Computer Underground (P-80 Systems).iso / misc / v05i020.txt < prev    next >
Internet Message Format  |  1992-09-27  |  27KB

  1. From:       Kenneth R. van Wyk (The Moderator) <krvw@CERT.SEI.CMU.EDU>
  2. Errors-To: krvw@CERT.SEI.CMU.EDU
  3. To:       VIRUS-L@IBM1.CC.LEHIGH.EDU
  4. Path:      cert.sei.cmu.edu!krvw
  5. Subject:   VIRUS-L Digest V5 #20
  6. Reply-To:  VIRUS-L@IBM1.CC.LEHIGH.EDU
  7. --------
  8. VIRUS-L Digest   Monday,  3 Feb 1992    Volume 5 : Issue 20
  9.  
  10. Today's Topics:
  11.  
  12. re: Boot Sectors Nomenclature (PC)
  13. .SYS Infector Mentioned In Ferbrache's Book (PC)
  14. Empire Virus/Central Point AV (PC)
  15. CHKDSK and Viruses (PC)
  16. Re: Stoned (PC)
  17. virus or hardware failure ? (PC)
  18. Flip Virus and Prof. Brunnstein (PC)
  19. Naming conventions (PC)
  20. VMS Virus detection (VAX/VMS)
  21. Comment on Cohen (was re: Cohen's Error)
  22. Collecting Infection Information for Paper.
  23. Re: FAQ: benign use of viri...
  24. Re: Trojan definition? Special case
  25. Re: Iraqi Virus Question?
  26. Re: New to the forum - question
  27. (Beware the) Ides of March
  28.  
  29. VIRUS-L is a moderated, digested mail forum for discussing computer
  30. virus issues; comp.virus is a non-digested Usenet counterpart.
  31. Discussions are not limited to any one hardware/software platform -
  32. diversity is welcomed.  Contributions should be relevant, concise,
  33. polite, etc.  (The complete set of posting guidelines is available by
  34. FTP on cert.sei.cmu.edu or upon request.)  Please sign submissions
  35. with your real name.  Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU
  36. (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks).
  37. Information on accessing anti-virus, documentation, and back-issue
  38. archives is distributed periodically on the list.  Administrative mail
  39. (comments, suggestions, and so forth) should be sent to me at:
  40. krvw@CERT.SEI.CMU.EDU.
  41.  
  42.    Ken van Wyk
  43.  
  44. ----------------------------------------------------------------------
  45.  
  46. Date:    30 Jan 92 11:25:44 -0500
  47. From:    "David.M.Chess" <CHESS@YKTVMV.BITNET>
  48. Subject: re: Boot Sectors Nomenclature (PC)
  49.  
  50. >From:    "Otto.Stolz" <RZOTTO@DKNKURZ1.BITNET>
  51.  
  52. Good summary of the situation!  We always use "MBR" for the MBR around
  53. here, so I like the choice of term...  *8)
  54.  
  55. One tiny extra complication: I believe that the secondary boot sectors
  56. (the ones that the MBR loads) sometimes behave just like the MBR does;
  57. that is, they divide up the space that they own into still more
  58. partitions, and load and pass control to yet another level of boot
  59. sector.  I've never had this confirmed directly, but of course since
  60. those boot sectors can do anything at all, they can certainly do this.
  61. The important question is whether or not the third-level boot sectors
  62. can get infected by any existing virus; I think the answer is no, but
  63. I'm not sure (It would also be nice to know if DOS ever does this,
  64. with "logical partitions" for instance, or if it's just theoretically
  65. possible.)
  66.  
  67. >I'd rather see a better term for the following one (suggestions?):
  68. >
  69. >Partition Boot Sector    : A genuine term for the 1st (logical) sector of
  70. >                           a partition on a HD, if you do not want to
  71. >                           refer to a particular operating system.
  72. >                           **Try to avoid this term, as some readers will
  73. >                           confuse it with the PT (or even with the MBR,
  74. >                           due to sloppy language in the past)**
  75.  
  76. We tend to use "System Boot Sector" for this, since that's the boot
  77. sector that actually loads an operating SYSTEM.  An even less
  78. ambiguous term, for when confusion is likely, would be "Operating
  79. System Boot Sector".  Although that's a little long for everyday use.
  80. OSBS?  *8)
  81.  
  82. - - --
  83. David M. Chess                                          mI' jIHbe' jay'!
  84. High Integrity Computing Lab                            loD tlhab jIH!
  85. IBM Watson Research                                          -- qama''e'
  86.  
  87. ------------------------------
  88.  
  89. Date:    Thu, 30 Jan 92 11:17:00 -0700
  90. From:    "Rich Travsky 3668 (307) 766-3663/3668" <RTRAVSKY@corral.uwyo.edu>
  91. Subject: .SYS Infector Mentioned In Ferbrache's Book (PC)
  92.  
  93. I'd asked about .SYS infectors in an earlier post. I came across a
  94. mention of one in David Ferbrache's new book (A Pathology Of Computer
  95. Viruses).  This .SYS infecting virus was called Pac-Man (makes a
  96. pacman character that eats characters on the screen). It infected
  97. MSDOS.SYS and was reported to this list by its author, Roger Gonzalez.
  98. Time frame for this was around 1988 it appears. The virus was never
  99. released. Apparently its purpose was only to demonstrate the
  100. feasiblity of .sys infectors.
  101.  
  102. Hmmm. I wonder if I feel motivated enough to poke through the archives
  103. of this list to find this old reference... :)
  104.  
  105. Richard Travsky
  106. Division of Information Technology     RTRAVSKY @ CORRAL.UWYO.EDU
  107. University of Wyoming                  (307) 766 - 3663 / 3668
  108.  
  109. ------------------------------
  110.  
  111. Date:    Thu, 30 Jan 92 13:44:26 -0500
  112. From:    James_Williams%ESS%NIAID@nih3plus
  113. Subject: Empire Virus/Central Point AV (PC)
  114.  
  115. I just got hit by a version of the Empire Virus which is not detected
  116. by Central Point AV but is detected by F-Prot and McAfee's Scan.
  117.  
  118. If anyone has any documentation about this virus, please let me know.
  119.  
  120. Thanks
  121.  
  122. - --------------------------------------------
  123. | James Williams                           |
  124. | Bitnet: JWW%ESS%NIAID@NIH3PLUS.BITNET    |
  125. | Internet: JWW@ESS.NIAID.PC.NIAID.NIH.GOV |
  126. | CompuServ: 70304,2462                    |
  127. - --------------------------------------------
  128.  
  129. ------------------------------
  130.  
  131. Date:    Thu, 30 Jan 92 16:05:59 -0500
  132. From:    Arthur Gutowski <AGUTOWS@WAYNEST1.BITNET>
  133. Subject: CHKDSK and Viruses (PC)
  134.  
  135. In issue 17, padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) writes:
  136.  
  137. >Actually, there are quite a few things that can cause CHKDSK to return
  138. >less than "655,360".
  139. >{details deleted}
  140.  
  141. Just like to add some experience with recently putting DOS 5.0 on my
  142. machine.
  143.  
  144. I noticed when running DOS 3.3 on my IBM PS/2 Mod50Z that chkdsk used to
  145. report 654336 of memory.  Now, with DOS 5.0, CHKDSK reports 655360.
  146. I don't really know what the cause of this was, and I'm not too
  147. interested in finding out (now that I'm DOS 5, I plan to wipe out
  148. all my DOS 3 bootable utility floppies, and recreate them with DOS 5).
  149.  
  150. More interesting, though, is the new MEM command available with DOS 5.
  151. When I run MEM, it reports 655360 total conventional memory, and
  152. 654336 bytes available to IBM DOS.  Since I'm reasonably sure that my
  153. DOS distribution diskettes were clean (and write protected), and I
  154. know I haven't booted from a floppy since installing DOS 5, I am
  155. reasonably sure that my system is not infected.  F-Prot 2.01 also reports
  156. that the system is fine.  However, the F-MMAP program from F-Port 1.16
  157. reports 654336 (639K) base memory.  This could be because it is talking
  158. to DOS, and not the hardware.  The memory allocation analysis part of
  159. F-Prot 2.01 doesn't reveal anything abnormal.
  160.  
  161. Does anyone have enough experience with DOS 5 to explain this 1K
  162. discrepancy (Padgett?) ?
  163.  
  164. Regards,
  165.     Art
  166. *****************
  167. Arthur J. Gutowski          Agutows@cms.cc.wayne.edu
  168. Wayne State University      "There is no dark side of the moon, really.
  169.                              Matter of fact, it's all dark."
  170.  
  171. ------------------------------
  172.  
  173. Date:    30 Jan 92 15:54:00 -0600
  174. From:    "William Walker C60223 x4570" <WALKER@aedc-vax.af.mil>
  175. Subject: Re: Stoned (PC)
  176.  
  177. Gary Huntress ( <HUNTRESS%V70D.decnet@npt.nusc.navy.mil> ) writes:
  178. > I found and cleaned Stoned from my system this weekend (f-prot is
  179. > *GREAT*).  I have no idea how long it had been resident, and since I
  180. > never saw it trigger (never got the message "You have been stoned"), I
  181. > started to wonder what causes it to trigger.  A date?  A number of
  182. > boots?  Random?
  183.  
  184. Stoned (or at least Stoned-E) displays its message according to the
  185. following:
  186.  
  187.         1.  If the machine was booted from an infected floppy, and
  188.         2.  If the timer byte at 0000:046C is 07.
  189.  
  190. So, for all boots from infected floppies, this has the effect of
  191. displaying the message in a pseudo-random pattern, averaging about 1
  192. out of every 8 boots.  This number matches what I have seen, both
  193. experimentally and "in the wild."  However, the hard disk will be
  194. infected following ANY boot from an infected floppy.
  195.  
  196. If the machine is booted from an infected hard drive, the message is
  197. never displayed.
  198.  
  199. Hope this answers your questions.
  200.  
  201. Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) | "If 'pro-' is the opposite of
  202. OAO Corporation                        |  'con-,' then is 'progress' the
  203. Arnold Engineering Development Center  |  opposite of 'Congress?'"
  204. M.S. 120                               |         - Gallagher
  205. Arnold Air Force Base, TN  37389-9998  |
  206.  
  207. ------------------------------
  208.  
  209. Date:    Thu, 30 Jan 92 23:24:13 +0000
  210. From:    mbeyer@ub-gate.UB.com (Mark Beyer)
  211. Subject: virus or hardware failure ? (PC)
  212.  
  213. Hi, folks.
  214.  
  215. I'm having a problem with my PC and I'm wondering if I've got a virus.
  216. Lately I've had problems running certain programs which had been
  217. running fine.  These programs fail with illegal instructions (trapped
  218. by QEMM) or they just won't load.
  219.  
  220. The problems have been getting progressively worse.  And yesterday, my
  221. floppies died and the whole machine now locks up if I hit "Num Lock".
  222. I figured it must be hardware failure or a virus, but hardware diags
  223. and McAfee Scan don't report anything unusual.
  224.  
  225. I also thought it might be a UMB conflict, but I removed QEMM and it 
  226. still croaks.
  227.  
  228. Any clues ?  Does this sound like a familiar virus to you ?
  229.  
  230. Thanks!
  231. - --
  232. Mark Beyer
  233. mbeyer@ub.com
  234.  
  235. ------------------------------
  236.  
  237. Date:    Thu, 30 Jan 92 19:50:08 -0500
  238. From:    Paul Bradshaw <ACDPAUL@vm.uoguelph.ca>
  239. Subject: Flip Virus and Prof. Brunnstein (PC)
  240.  
  241. In light of the recent conflict between Fprotect and CPAV I decided I
  242. was interested in getting more information about the Flip virus.
  243.  
  244. I was astonished to find that it's not contained in the copies of
  245. Prof. Brunnsteins virus list at cert.sei.cmu.edu, nor at any of the
  246. other ibm-anti-viral sites.  Does anyone out there know where I can get
  247. a complete up-to-date version of this list?  Does anyone know where I
  248. can get a good description of the Flip virus?
  249.  
  250. Additionaly, where are Patricia Hoffmann's virus lists at?  Are they not
  251. available as shareware?  I know this has likely already been covered in
  252. Virus-L but my memory is only so good :-)
  253.  
  254. Thanks very much in advance for replying to my post.
  255.  
  256. Paul Bradshaw
  257. acdpaul@vm.uoguelph.ca
  258. cs0872@snowhite.uoguelph.ca
  259.  
  260. ------------------------------
  261.  
  262. Date:    Thu, 30 Jan 92 11:30:44 -0500
  263. From:    padgett%tccslr.dnet@mmc.com (A. Padgett Peterson)
  264. Subject: Naming conventions (PC)
  265.  
  266. >From:    "Otto.Stolz" <RZOTTO@DKNKURZ1.BITNET>
  267.  
  268. >Summary of the terms suggested:
  269.  
  270. >Master Boot Record (MBR) : The 1st physical sector on a hard disk
  271. >                           **Cease calling it Partition Table|**
  272. and add:                    must follow format proscribed by the BIOS.
  273.  
  274. After all Sun stations and Macintoshes have MBRs like PCs just follow
  275. different formats.
  276.  
  277. >Partition Table          : A particular part of the MBR.
  278. >                           **Use this term only when particularaly
  279. >                           referring to this part of the MBR, as opposed
  280. >                           to other parts**
  281. and add                     Used to define the logical partition structure
  282.                             of the disk
  283.  
  284. Then we should also have the following:
  285.  
  286. Master Boot Record Program: Executable program placed in the Master Boot
  287.                             Record area preceeding the Partition Table
  288.                             that begins the boot of a fixed disk.
  289.  
  290.  
  291. >DOS Boot Sector          : The 1st (logical) sector of a DOS partition on
  292. >                           a hard disk, or the 1st (physical and logical)
  293. >                           sector of a DOS diskette.
  294. >                           (Similar terms to be coined for other
  295. >                           operating systems)
  296.  
  297. >Partition Boot Sector    : A genuine term for the 1st (logical) sector of
  298. >                           a partition on a HD, if you do not want to
  299. >                           refer to a particular operating system.
  300. >                           **Try to avoid this term, as some readers will
  301. >                           confuse it with the PT (or even with the MBR,
  302. >                           due to sloppy language in the past)**
  303.  
  304. These would actually refer to the same thing only that the PBR (I like
  305. Logical Boot Sector or LBR better)
  306.  
  307. The following applies only to a DOS system though I would expect similar
  308. constructs to exist in OS/2 and Unix for Intel platforms.
  309.  
  310. DOS Boot Record (DBR)     : The first logical sector of a DOS partition
  311.                             (first logical is also the first physical sector
  312.                              on most floppies)
  313.                             Contains the BPB (Boot Parameter Block - analagous
  314.                              to the partition table) and Boot Record Code
  315.  
  316. DOS Boot Record Code      : Executable code found in the first logical sector
  317.                             of a DOS partition. If the partion is to be used
  318.                             for booting (is ACTIVE partition), it must conform
  319.                             to DOS specifications.
  320.  
  321. DOS BPB                   : Data table found at a specified location in the
  322.                             first logical sector of a DOS partition that
  323.                             specifies the organization of the partition.
  324.  
  325.                     Warmly,
  326.                         Padgett
  327.  
  328. ------------------------------
  329.  
  330. Date:    30 Jan 92 16:51:32 +0000
  331. From:    peterh@richsun.cpg.trs.reuter.com (Peter Heinicke)
  332. Subject: VMS Virus detection (VAX/VMS)
  333.  
  334. One of my clients has a contract which specifies that some VMS
  335. software be virus-free. Right. Now is there any avaliable way of
  336. checking that to the best of our ability. (Like Norton Anti Virus for
  337. VMS). Its obvious to me that such a package would not be foolproof,
  338. but at least it would show a prudent man effort. I have heard of one
  339. VMS DECnet worm, but no viruses, and I would be interested if anybody
  340. had heard of a VMS virus. Please email responses and I will summarize,
  341. within a week.
  342.  
  343. +-------------------------------------------------------------------------+
  344. |Peter H. Heinicke              Would you feel comfortable owing
  345. |Technical Consultant           three times your annual income to the Japanese
  346. |                and other potentially hostile creditors?
  347. |                               Then why add to the National Debt?
  348. |708-393-6478 (voice)
  349. |708-574-7424 x2817 (voice)
  350. |708-393-4203 (fax)
  351. |peterh@richsun.cpg.trs.reuter.com (Email) 
  352.  
  353. ------------------------------
  354.  
  355. Date:    Thu, 30 Jan 92 11:14:41 -0500
  356. From:    padgett%tccslr.dnet@mmc.com (A. Padgett Peterson)
  357. Subject: Comment on Cohen (was re: Cohen's Error)
  358.  
  359. >From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  360.  
  361. Vesselin makes an excellent description of logic (which I haven't entirely
  362. gone through, yet) but do wish to reiterate a simple concept.
  363.  
  364. Computers are designed to run programs. Viruses are programs. e.g. Computers
  365. are designed to run viruses. - Old Adage
  366.  
  367. Viruses perform actions which SHOULDN'T occur during normal computer operation
  368. except in special cases. - My thought.
  369.  
  370. Viruses cause changes - its in their charter.
  371.  
  372. Therefore, viruses ARE detectable by looking for changes (or attempted changes)
  373. that should not occur.
  374.  
  375. The basic problem with most anti-virus defenses is that they are layered on
  376. top of the operating system while according to industry reports most infections
  377. occur before the operating system is loaded.
  378.  
  379. For several years, I have been trying to present the concept of BIOS level
  380. integrity management & have been giving away demonstrators, yet no-one seems
  381. particularly interested. I do believe that if simple integrity checking were
  382. put into the code used by FDISK and FORMAT, the spread of MBR infections
  383. including STONED, AZUSA, AIRCOP, EMPIRE, MICHELANGELO, etc could be stopped.
  384. Period.
  385.                         Warmly,
  386.  
  387.                             Padgett
  388.  
  389. ------------------------------
  390.  
  391. Date:    Thu, 30 Jan 92 17:16:13 -0500
  392. From:    Uwe Hauck <UWEHAUCK@DOSUNI1.BITNET>
  393. Subject: Collecting Infection Information for Paper.
  394.  
  395. I am working at the University of Osnabrueck (Germany) on a Paper
  396. concerning Viral Infections of Research Computer Systems, how they
  397. infected, how they were detect and what the Departments do to get rid
  398. of them. So I am searching for actual Information about ''Infections''
  399. in the last 6 Month, and about your Experiences with Virus-Protection
  400. methods.
  401.  
  402. Any comments on that topic will be welcome and when the paper is
  403. finished I will send the Textfile to everyone interested (Preprints
  404. will go to everyone, who contributed directly !) This Paper will have
  405. the status of a free of charge documentation for our university and
  406. will not be published for money.
  407.  
  408. Please send any contributions to
  409.  
  410. UweHauck at dosuni1.bitnet
  411. UweHauck at dosuni1.rz.uni-osnabrueck.de
  412. Thanx a lot....
  413.  
  414. ------------------------------
  415.  
  416. Date:    30 Jan 92 21:18:17 +0000
  417. From:    vail@tegra.com (Johnathan Vail)
  418. Subject: Re: FAQ: benign use of viri...
  419.  
  420. euzebio%dcc.unicamp.ansp.br@UICVM.UIC.EDU (Marcos J. C. Euzebio) writes:
  421.  
  422.    Does anybody have any experience/references/etc. on
  423.    the use of viri/worms as a paradigm for distributed applications?
  424.  
  425. Back in 1980 as a high school senior I read a newspaper article about
  426. research at xerox PARC.  It was research on "worms".
  427.  
  428. This was the inspiration for me to try and make one on an Apple ][,
  429. although mine was technically a virus (a boot sector virus if you want
  430. to be really technical).
  431.  
  432. I have asked here before if anyone has pointers to the xerox research
  433. but no one else remembers it.
  434.  
  435. Maybe this time it rings a bell?
  436.  
  437. jv
  438.  
  439. "Koukinaries"
  440.  _____
  441. |     | Johnathan Vail     vail@tegra.com     (508) 663-7435
  442. |Tegra| jv@n1dxg.ampr.org    N1DXG@448.625-(WorldNet)
  443.  -----  MEMBER: League for Programming Freedom (league@prep.ai.mit.edu)
  444.  
  445. ------------------------------
  446.  
  447. Date:    30 Jan 92 21:52:45 +0000
  448. From:    vail@tegra.com (Johnathan Vail)
  449. Subject: Re: Trojan definition? Special case
  450.  
  451. bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
  452.  
  453.    vail@tegra.com (Johnathan Vail) writes:
  454.    > ________________
  455.    > trojan (horse) - This is some (usually nasty) code that is added to,
  456.    >     or in place of, a harmless program.  This could include many viruses
  457.    >     but is usually reserved to describe code that does not replicate
  458.    >     itself.
  459.    > ________________
  460.  
  461.    Hmm, the definition is not that bad, but I think that a more exact one
  462.    would be "a program, which intentionally performs some undocumented
  463.    functions"... Oh well.
  464.  
  465. In a clinical sense your definition is correct but in reality can
  466. apply to most "real" programs, like DOS.  When I think of a Trojan
  467. Horse program I would think of something like the "tampered" versions
  468. of PKZIP that were around a year or two ago.  Or a program called
  469. soemthing like FREESEX that would lecture you about morality and lock
  470. format your hard disk.
  471.  
  472. jv
  473.  
  474. "Don't try this at home kids"
  475.  _____
  476. |     | Johnathan Vail     vail@tegra.com     (508) 663-7435
  477. |Tegra| jv@n1dxg.ampr.org    N1DXG@448.625-(WorldNet)
  478.  -----  MEMBER: League for Programming Freedom (league@prep.ai.mit.edu)
  479.  
  480. ------------------------------
  481.  
  482. Date:    30 Jan 92 21:42:21 +0000
  483. From:    vail@tegra.com (Johnathan Vail)
  484. Subject: Re: Iraqi Virus Question?
  485.  
  486. 379BMWMASQ@sacemnet.af.mil (379BMWMASQ) writes:
  487.  
  488.     I have been watching in the list the message treads on the Iraqi printer
  489.    virus, and I have a question to pose to the group.
  490.  
  491.        1. Postscript printers receive printouts in the form of Postscript
  492.           Program Code, which is in turn run by the printer to printout
  493.           the Page. Now if that Postscript printer is on a Network and
  494.           is capable of sending information to the network, then could
  495.           the printer CPU be programmed to access the well known and
  496.           some not so well known security features of the network to
  497.           plant code or overload the system with bogus traffic.
  498.  
  499. Yes, this is entirely possible, but not very likely.  It would be
  500. especially hard for the postscript code itself to contain a virus or
  501. worm.  I am speculating about what could be possible with a bogus
  502. printer.  Note that this is an entirely separate issue from the
  503. postscript password issue.
  504.  
  505. Some types of networked postscript printers:
  506.  
  507. Appletalk - I am not an expert on the protocol and it may be that
  508.   "printer" devices cannot legally go out on the network of their own
  509.   accord.  But one could, in theory, mimic being a computer itself and
  510.   alter files on connected machines.
  511.  
  512. TCP/IP Etherent (BSD spooling) - Here the printer is actually a full blown
  513.   "host" computer as far as the network is concerned.  It could, in
  514.   theory, use NFS, Telnet, FTP, finger, etc., and exploit whatever
  515.   holes there are to be found.
  516.  
  517. SCSI - Not a full blown network but if the hosts system's disks are on
  518.   the same physical bus then the printer can get at them any way it
  519.   wants.
  520.  
  521. jv
  522.  
  523. "Koukinaries"
  524.  _____
  525. |     | Johnathan Vail     vail@tegra.com     (508) 663-7435
  526. |Tegra| jv@n1dxg.ampr.org    N1DXG@448.625-(WorldNet)
  527.  -----  MEMBER: League for Programming Freedom (league@prep.ai.mit.edu)
  528.  
  529. ------------------------------
  530.  
  531. Date:    Fri, 31 Jan 92 03:23:46 +0000
  532. From:    seeger@oceania.com(Seeger Fisher)
  533. Subject: Re: New to the forum - question
  534.  
  535. bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
  536. > geoffb@coos.dartmouth.edu (Geoff Bronner) writes:
  537. > > Since I run a cluster and support dozens of macs and ibms directly I
  538. > > see them more often. ...
  539. > > ...I see an infected disk maybe once a week. 
  540. > Just out of interest, here at the VTC, we get averagely one to two
  541. > requests for help per week, from all over the Germany. I don't know,
  542. > maybe for some people this means that the computers in Germany are
  543. > "very prone" to viruses... 
  544.  
  545. I suppose some people might think that the computers in Germany
  546. are "very prone" to viruses, but none that ever posted to this
  547. newsgroup. Unless, of course, there are a grand total of several
  548. dozen computers in all of Germany!     ;)
  549. - -- 
  550. seeger@oceania.com
  551.  
  552. ------------------------------
  553.  
  554. Date:    Fri, 31 Jan 92 11:37:38 -0500
  555. From:    Kenneth R. van Wyk <krvw@cert.sei.cmu.edu>
  556. Subject: (Beware the) Ides of March
  557.  
  558.          Who SHOULD attend this year's Ides-of-March
  559.        Fifth International Computer VIRUS & SECURITY Conference
  560.       at the New York Marriott Marquis and Loews New York Summit
  561.  
  562. MIS Directors, Security Analysts, Software Engineers, Operations
  563. Managers, Academic Researchers, Technical Writers, Criminal
  564. Investigators, Hardware Manufacturers, Lead Programmers who are
  565. interested in:
  566.  
  567. WORLD-RENOWNED SECURITY EXPERTS      CRIMINAL JUSTICE LEADERS:
  568.    Marchall Abrams - Mitre              Carol Bernstein - IBM Counsel
  569.    Robert Campbell - AIM                Buck Bloombecker - NCCD
  570.    Jon David - Systems R&D              Scott Charney - US Justice Dept
  571.    Harold Highland - Comp & Security    Ken Citarella - Westchester DA
  572.    Bill Murray - Deloitte               Don Delaney - NY Comp. Crime Lab
  573.    Jane Paradise - Apple                Dennis Jackson - Scotland Yard adv.
  574.    Donn Parker - SRI                    Steve Purdy - Kroll (former US SecSvc)
  575.    Maria (Pozzo) King                   Marc Rotenberg - CPSR
  576.    Dennis Steinauer - NIST              Gail Thackeray - Phoenix County
  577.  
  578. UNIVERSITY:             PRODUCTS:                TELECOM:
  579.  Vesselin Bontchev        Dave Chess - IBM SCAN      Manuel Barbero (Fr. Tel)
  580.  FrB Klaus Brunnstein     Fred Cohen - ASP           Bill Cheswick (AT&T)
  581.  Yvo Desmedt (Wis)        Andy Hopkins - Panda       Tom Duff (AT&T)
  582.  Dmitry Gryaznov*         John McAfee - SCAN         Ed Fulford (Northern Tel)
  583.  Karl Levitt (UC Davis)   Dick McClung - Watchman    Tom Papa (Locate)
  584.  Fugene Spafford (Purdue) Fridrik Skulason - F-PROT  Meg Reilly (MCI)
  585.  Yisrael Radai*           Al Solomon - Dr. Toolkit   John Toomey (LeeMah)
  586.  Ken van Wyk - Carnegie Mellon
  587.  
  588. (* Possible Alternates)
  589.  
  590. Over 53 PRODUCT DEMOS including: 
  591. Candle's Deltamon, HJC's Virex, McAfeeSCAN, Symantic's SAM, Norton
  592. Antivirus, Central Point, ASP 3.0, DDI's Physician, Gilmore's FICHEK,
  593. Certus, FluShot Plus, PC Cillin, Virus Free, Quarantine, PC Tools,
  594. Virex, Detective, Assassin, Untouchable, Vaccine, Bear Trap, Disk
  595. Defender, Top Secret, Omni, ACF2, RACF, and OTHERS AS REGISTRANTS
  596. REQUEST.
  597.  
  598. SIXTY ONE PRESENTATIONS INCLUDE:
  599. Trust & Org Policy, OSI/PBX/ISDN/voice, Euro '92 (Law, USSR), Access &
  600. Encryption, UNIX I - PC & Mainframes, Warfare Programs, Disinfecting
  601. the LAN Server, LAN HW/SW Defenses, LAN Policy & Disaster, Risk
  602. Software, DEC products, MAC products, LAN products, UNIX II -
  603. Networks, Stalking Intruders, Telecom Security, Security/Virus
  604. Countermeasures, Anti-Virus Tekkies Delight, Dissecting the Pakistani
  605. Virus (Brain Surgery), What the Law Says, How We Caught 'Em - Current
  606. Crime Cases, Pursuing and Avoiding Telecom Fraud, Research and New
  607. Trends, Info Theft by Radiation, the Great Hacker Debate III...
  608.  
  609. INTERESTED?  ONLY $275 one day (Thurs 3/112 - Fri 3/13) or $375 both days:
  610.  *  Bound, 600-page Proceedings containing ALL materials - no loose paper!
  611.  *  Eight meal breaks, including Meet-the-Experts cocktail party
  612.  *  Two 2-day tracks of product demo's   *  Optional Security course Wed 3/11
  613.  *  Full-time LAN Track                  *  Full-time Legal & Justice Track
  614. $20 additional for those who are not ACM/IEEE/CMA, ISSA/DPMA members.
  615. Fourth member in each group gets in for no charge!   Late fee after 2/17/92.
  616.  
  617. To register by mail, send check payable to DPMA, card number (VISA/MC/AMESX)
  618.   or purchase order to:         Virus Conference Security Conference
  619.                                 DPMA
  620.                                 Financial Industries Chapter
  621.                                 Box 894
  622.                                 New York, NY 10268
  623.  or fax to (303) 825-9151.  Be sure to include your member number if
  624.  requesting the discounted rate.  Registrations received after 2/17/92
  625.  are $425, so register now!
  626.  
  627. For registration information/assistance, call (800) 
  628. Downloaded From P-80 International Information Systems 304-744-2253
  629.